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Description 
Knowledge-Driven Architecture 

Cross Reference To Related Applications 

[0001] The present application is based on the Applicant's U.S. 
Provisional Patent Application #60532384, entitled 
"Knowledge-driven Architecture," filed on December 29, 
2003. 

Background of Invention 
Field of the Invention 

[0002] The present invention relates generally to the field of 
software architecture. More specifically, the present in- 
vention discloses a method that integrates software and 
knowledge engineering in knowledge-driven architecture. 
The method allows developers or business experts to 
quickly build a software application layer by describing 
application flow as a set of scenarios and introducing ap- 
plication requirements as related business rules in a 
knowledgebase. An Application Scenario Player and a Ser- 
vice Connector transform application scenarios into inter- 



actions with tlie l<nowledgebase, presentation compo- 
nents, and underlying application services. 
Background 

[0003] There is a gap in the current development process be- 
tween the initial business input provided by business ex- 
perts and the final implementation. The current process 
requires multiple transformations from user requirements 
into low-level programming functions and data tables. 
Multiple technology teams work hard to create multiple 
filter-layers to fill this gap and break the beautiful shapes 
of reality into small and simplistic pieces, transforming 
business rules into Boolean logics. 

[0004] This process hasn't changed much during the last twenty 
years. 

[0005] Some time ago, we thought of the C-language as a lan- 
guage for application development, while Assembly was 
the language for system development. Since the Assembly 
language was pushed down to the system level, we use 
languages like C, C++, C#, VB, and Java to code business 
algorithms in applications. This development paradigm 
has been in place for about 20 years. 

[0006] However, the current shift to service-oriented architec- 
tures and recent advances in knowledge technologies can 



allow us to cleanly separate generic services from applica- 
tion-level business rules and specific requirements of 
user-program or program-program interfaces. 

[0007] Using a knowledgebase, we can represent requirements as 
business rules described in "almost natural" language. We 
can finally shift our focus from ironing out all possible 
business cases in our design and code to creating flexible 
application mechanisms that allow us to change and in- 
troduce new business rules on-the-fly. 

[0008] vVe can also improve the pattern recognition process. 
Imagine that a set of rules which defines a recognition 
process, for example in a grammar file, is enhanced with 
the ability to access a knowledge engine. This would 
promise more intelligent recognition, based not only on 
the multiple choices prepared in the file, but also on ex- 
isting facts and rules of the available world of knowledge, 
associations between related topics, etc. 

[0009] Software applications often represent a new combination 
of existing software components. These components of- 
ten need to be polished or changed to fit into a new ap- 
plication mosaic. Service components are glued and com- 
piled together with specific business rules, expressed as 
programming algorithms, that distinguish the application. 



Creating an application is a project, often a big project, 
for multiple teams; the initial team of business experts 
that know "what should be done" is just the tip of the ice- 
berg. This invention can improve the development process 
by decreasing the transformation steps required, and thus 
stop the business requirements from getting watered 
down and distorted during the process. 
Summary of Invention 

[0010] The invention provides a better separation between 

generic service components and specific rules and scenar- 
ios that characterize the application. Services in a knowl- 
edge-driven architecture are integration-ready compo- 
nents presented at the service layer locally or distributed 
over the network. Business rules and scenarios that repre- 
sent a very light application layer can be created and 
changed at run-time by business experts, who would have 
their chance to influence application behavior, and to say 
not only "what should be done," but also "how". 

[0011] The main component of the application is the knowledge- 
base, which stores application requirements as application 
scenarios and business rules. The Application Scenario 
Player and the Service Connector transform application 
scenarios into interactions with the knowledgebase, pre- 



sentation components, and underlying application ser- 
vices. 

[0012] Knowledge-driven architecture includes elements and 
mechanisms that provide information about the knowl- 
edge and services existing on distributed knowledge sys- 
tems built with this architecture. 

[0013] These mechanisms and the collaborative mechanisms de- 
scribed in the Distributed Active Knowledge and Process 
Base (see Jeff Zhuk, United States Patent Application, Dis- 
tributed active knowledge and process base, 
2010044827, Al, http://uspto.gov ) allow separate sys- 
tems to negotiate multiple forms of collaboration: to 
share or trade knowledge and services with sufficiently 
flexible levels of security. 
Brief Description of Drawings 

[0014] The present invention can be more readily understood in 
conjunction with the accompanying drawings, in which: 

[0015] Fig. 1 is a diagram that shows the major blocks of knowl- 
edge-driven architecture. 

[0016] Fig. 2 shows details of the Presenter and knowledgebase 
components 

[0017] Fig. 3 is a collaboration diagram that describes the inter- 
action between the components 



[0018] Fig. 4 illustrates details of the Service Connector component. 
[0019] Fig. 5 discloses details of the Scenario Player. 
Detailed Description 



Fig. 1 

[0020] Turning to FIG. 1, the present invention consists of the 

knowledgebase 100 as the main component that collabo- 
rates with the application scenario player 200 and the ser- 
vice connector 300. The application scenario player 200 
interprets application scenarios and interacts with the ser- 
vice connector 300 and presentation components 400. 
The service connector 300 provides access to the knowl- 
edgebase 100 and service components 500. This is the 
Functional View (or the Component View) of the architec- 
ture. Application requirements are directly represented by 
the business rules stored in the knowledgebase. A flow of 
application information as well as interactions between 
users and the program or/and between partner programs 
are described by application scenarios written with an XML 
based application scenario language (ASL). 

[0021] vVe can review the diagram from the position of the 

Model-View-Controller Design Pattern. From this point of 
view, the knowledgebase with business rules and scenar- 



ios, together with application service components, repre- 
sent the Model. The presentation components represent 
the View. The Scenario Player 200 and the Service Con- 
nector 300 represent the Controller. 

[0022] The major component of the Model is the knowledgebase 
or Knowledge Engine (KE) 100. Business rules are cap- 
tured in the knowledgebase with an "almost natural" on- 
tology language like CycL. A user or program agent 600 
can also transmit an application scenario to the controller. 
Application scenarios are written in the Application Sce- 
nario Language. The Application Scenario Language allows 
developers or business experts to describe application 
flow as a set of scenario acts with conditional service in- 
vocations. The scenario acts can describe interactions be- 
tween users and programs or between partner programs 
engaged in a common business transaction, and include 
calls to knowledgebase services for application business 
rules and related data. 

[0023] Traditional services, which are written with current pro- 
gramming languages like C# or Java and compiled into bi- 
nary service components, can also capture some business 
rules and algorithms to support the Model. Services are 
designed as integration-ready components with separate 



APIs required by the Service Connector 300. The Service 
Connector 300 transforms service requests from applica- 
tion scenario acts into direct calls to service components 
500. 

[0024] Each application scenario is a set of scenario acts. Each 
act is a very lightweight XML description that can invoke 
some services, exercise conditions or business rules, and 
include rules for the interpretation of expected user or 
program agent responses. 

[0025] There is a traditional View block of the MVC design pat- 
tern. The View delivers information in selected video, 
sound, or electronic formats; people as well as partner 
programs are its target audience. In the future, we will re- 
fer to presentation components or the View as the Presen- 
ter 400. 

[0026] The Scenario Player 200 is connected via the Service Con- 
nector 300 to the knowledgebase 100 and other services 
500 that represent a business model, and actively uses 
the knowledgebase 100 in the process of application sce- 
nario interpretation. 

[0027] The input information for the Scenario Player 200 can be 
data entered by a user via voice or any other method, an 
XML service request from the network, or an act of an ap- 



plication scenario. The Scenario Player 200 interacts with 
the Service Connector 300 that provides access to the 
knowledgebase 100 and traditional services 500, as well 
as to the Presenter 400, which transforms resulting data 
into the proper format. The format depends on two fac- 
tors. A specific implementation of the Presenter 400 that 
gears towards specific video, audio, or electronic formats 
is a fixed factor. An application scenario can include some 
presentation definition-rules that provide extra flexibility 
for the presentation layer. 
[0028] The Scenario Player 200 is also responsible for the inter- 
pretation of service or knowledgebase responses. Inter- 
preted responses are directed to the Presenter 400, which 
performs the final transformational steps and delivers 
data to the target audience in the selected presentation 
format. 

[0029] The Presenter 400 can include special engines, like 

speech, handwriting, or image recognition, which might 
target a specific type of user input. 

[0030] Scenarios can describe sequences of expected events re- 
lated to multiple agents 600, and provide rules on han- 
dling these events. These scenarios will map each ex- 
pected event to its observer object, or a set of observers 



that have interest in the events and handle them with the 
proper services 500. 
[0031] The functionality described above provides for great flexi- 
bility, but can suffer in performance. The Optimizer 700 
takes a snapshot of existing rules and scenarios and 
translates them into source, for example in Java or C#. 
This source can later be compiled into binary code to iron 
the current status of application rules into a regular appli- 
cation that lacks flexibility but provides better perfor- 
mance. 
Fig. 2 

[0032] Fig. 2 shows details of the Presenter 400 and knowledge- 
base 100 components. 

[0033] The Presenter 400 can include the Communicator 420, the 
Performer 440, and the Formatter 460 components. 

[0034] The Formatter 460 prepares data for audio or video inter- 
action or for communication to other programs. HTML is 
an example of such formatting. The Performer 440 com- 
ponent uses formatted data for actual presentation via 
voice or screen. The Performer 440 can be implemented in 
multiple ways for different client device types. For exam- 
ple, the Performer 440 can display HTML data via the rich 
graphical interface of a thick client device or workstation. 



The Communicator 420 is responsible for formatted data 
communications via peer-to-peer distributed networks or 
otiier protocols. 

[0035] Knowledge and service elements can be distributed over 
the network, where they can promote their abilities and 
can be accessed via the Communicator 420 using the col- 
laborative mechanisms described in the Distributed Active 
Knowledge and Process Base (see Jeff Zhuk, United States 
Patent Application, Distributed active knowledge and pro- 
cess base, 2010044827, Al, http://uspto.gov). 

[0036] The knowledgebase 100 component includes the knowl- 
edge service component 120 and the knowledge engine 
140. 

[0037] The KnowledgeService 120 component serves as the adapter 
to the knowledge engine 140, and adapts the knowledge 
engine interface to the interface required by the Service 
Connector 200. 
Fig. 3 

[0038] The collaboration diagram in Fig. 3 describes interaction 

between the components. 
[0039] The diagram simplifies the activity of the application to 8 

major steps. 

[0040] #jhe ScenarioPlayer object receives an XML instruction 



from the network, as an act of a current scenario, or a 
user's input related to tlie scenario. 
•Tlie ScenarioPlayer Interprets tliis input and translates 
it into a service request directed to the ServiceConnec- 
tor (the most common action). 
•The ServiceConnector object uses its actQ method to 
connect to or obtain (load at run-time) a necessary 
service object that will perform the requested opera- 
tion/method. 

•The service object invokes the proper method with 
the necessary parameters, and delivers results back to 
the caller. 

•The ScenarioPlayer gets the results of the service, and 
passes them further to the Formatter object. 
•The Formflffer implementation translates results into a 
presentation format and produces XML scenarios re- 
lated to the expected user interaction. 
•The ScenarioPlayer interprets the results for the Per- 
former object if the operation was a success. If the op- 
eration failed (for example, the knowledgebase query 
returns a "not found" string), the ScenarioPlayer C3Lr\ use 
the Communicator peer (if present) to outsource this 
operation to a network of knowledge peers. 



•The Performer object presents results on a screen or/ 
and in a voice format. The alternative for this step is to 
communicate data to other peers (for example, if the 
local peer failed, another peer on the network may be 
able to resolve the request) or to partner programs. 

Fig. 4 

[0041] Fig. 4 illustrates the details of the ServiceConnector compo- 
nent. 

[0042] Each component in the figure represents a block of soft- 
ware responsible for the proper functionality of a compo- 
nent. 

[0043] The Actor 310 block is able to play multiple object roles. 
It takes service and action names as parameters, and in- 
vokes the requested method on the requested object type. 

[0044] The Actor 310 receives the name of the service and the 
name of the operation to perform with the required pa- 
rameters. The Actor 310 looks into the Object Registry 
330 to check if there is an existing object of the re- 
quested service class. If there is no such service object 
yet, the Actor 310 works with the Object Retriever 320 to 
load the requested service class and instantiate the object 
of this class at run-time. The Actor 310 then registers 
(stores) the retrieved object in the Object Registry 330. 



[0045] Multiple objects of the same service class are associated 
with object names. In this case, the Service Connector 200 
receives an object name as an additional argument to ser- 
vice and action names that identify the service class and 
the method names. The registered object keeps its state 
during its lifetime, which can include many service invo- 
cations. 

[0046] The next step is to use Method Retrieval 340 to retrieve 
the proper method, which will perform the requested ser- 
vice operation. The Method Retrieval 340 selects one of 
the methods of the selected service object based on the 
provided method parameters. The Actor 310 then uses 
the Method Performer 350 to perform the operation. 
[0047] jhe Service Connector can be implemented in Java, C#, or 
other languages that allow systems to load service objects 
at run-time based on their names. The Method Retrieval 
mechanism consists of three steps/trials. 
[0048] «use the method name and parameter types to find an 
exact match. For example, a Java implementation 
would use the mechanism offered by the 
Class.getMethodO method. 

•Unfortunately the exact match rarely happens in real 
programs. Parameter types are often subclasses of re- 



quired argument classes. The second step is to cliecl< 
for metliod compatibility instead of the exact match. 
For example, a Java implementation would use the 
mechanism offered by the Class.isAssignableFromO 
method. 

•It is possible that both trials will fail because of im- 
plementation issues. For example, Personal Digital As- 
sistants (PDA) or wireless phones do not have sufficient 
library support for such sensitive reflection mecha- 
nisms. In this case, the third attempt will invoice a spe- 
cific method of the service object that serves as the 
dispatcher for other methods of this service class. For 
example, it may call a method named "dispatch()"of 
that class according to the initial interface/agreement 
between the Service Connector and service classes. The 
"dispatch()"method takes the name of a service opera- 
tion (a method name) and the array of objects. These 
objects will be cast into specific types inside the "dis- 
patch()"method according to the requirements of the 
specified service method. 
[0049] jhe ScenarioPlayer 200 component is responsible for han- 
dling agent events. The ScenarioPlayer 200 also provides 
interpretation and performance of application scenarios. 



which contain rules for possible events and related han- 
dling procedures. 
[0050] Requested services can be implemented as service com- 
ponents 500 or as knowledgebase rules. 
Fig. 5 

[0051] Fig. 5 discloses details of the Scenario Player 200. 

[0052] The Scenario Player 200 consists of two major parts: the 
Interpreter and the Act Player presented in Fig. 5 with 
blocks 210-240 and 250-290 respectively. 

[0053] The Input Type Checker 210 checks current input and, 

depending on its type, submits the input to one of the in- 
terpreters. 

[0054] Knowledge-driven architecture includes elements and 
mechanisms that provide information about the knowl- 
edge and services existing on other istributed knowledge 
systems built with this architecture. These mechanisms 
include but are not limited to the Service Analysis 215 
component and learning scenarios. 

[0055] The Success Analysis 215 component provides a history of 
success, history of interpretation failures, and, in the case 
of interpretation failure, invokes one of the learning sce- 
narios that prompt an agent (a user or a program) to re- 



define the input or provide more details for better inter- 
pretation. If tlie learning scenario cannot be executed at 
that time (it was canceled, etc.), the scenario will be 
placed in the queue of scenarios with un-answered ques- 
tions to be played later and to resolve unsuccessful inter- 
pretations. 

[0056] Each service component can have usage and value prop- 
erties (see Jeff Zhuk, United States Patent Application, 
Distributed active knowledge and process base, 
2010044827, Al, http://uspto.gov ). The Success Analy- 
sis 215 component re-evaluates these properties after 
each service request. 

[0057] The set of interpreters includes but is not limited to the 
Scenario Act Interpreter 220, the Prompt Response Inter- 
preter 230, and the New Agent Request Interpreter 240. 

[0058] All interpreters transform original input into scenario 
player APIs or service component APIs. Interpreters are 
connected to the Presenter 400 and can use the Formatter 
460 and the Performer 440 services. For example, the in- 
put line can instruct the system to present information via 
a specified video or audio format. It is also possible that 
no current interpretation will be found. In this case, a de- 
fault learning scenario would be played, prompting an 



agent (a user or a program) to re-define the input or pro- 
vide more details. Default scenarios can be replaced at 
run-time with enhanced ones. 

[0059] Interpretation rules are stored in the knowledgebase 100. 
Interpreters interact with the Query Performer 280 to ac- 
cess the knowledgebase 100 via the Knowledge Service 
120. When existing rules fail, the learning scenario 
(default or not) is given the questionable unresolved in- 
put, and is called upon to retrieve new definitions or more 
details from an agent (a user or a program). Upon suc- 
cessful execution, the scenario ends up with one or more 
acts that re-define existing rules or/and add more rules 
to the knowledgebase. If the learning scenario cannot be 
successfully executed at this time, the scenario will be 
stored in the Queue of Scenarios 245, and will be tried 
again later. This provides for great flexibility, which is a 
welcomed feature for most business applications as well 
as educational systems. 

[0060] The Player part of the Scenario Player 200 consists of the 
Queue of Scenarios 245, the Scenario Modifier 250, the 
Current Scenario 255, the Next Act Retrieval 260, the 
Translator 265, the Alias Retrieval 270, the Condition 
Checker 275, the Query Performer 280, and the Service 



Performer 290. 

[0061] The Queue of Scenarios 245 stores the current scenario 

wlien it cannot be executed at the present time, but needs 
to be executed later on. For example, if a user cannot 
provide answers to a learning scenario at this moment, 
but can do so afterward. 

[0062] The Scenario Modifier 250 receives results from every step 
of playing the scenario act. If the current act resolves the 
value of any variable in the scenario, the Scenario Modifier 
250 replaces this variable with its value in the Current 
Scenario 255. For example, the scenario can include the 
variable PEER-GROUP-NAME. Any act of the scenario that 
resolves this variable will pass the variable name and its 
value to the Scenario Modifier 250, and the Scenario Mod- 
ifier 250 will replace this variable in the Current Scenario 
255 with the value of the variable. 

[0063] The Current Scenario 255 is loaded from the knowledge- 
base 100 or from the Queue of Scenarios 245, and can be 
updated with run-time values by the Scenario Modifier 
250. Any current scenario consists of scenario acts: sim- 
ple XML elements/instructions. Each instruction can be a 
prompt to an agent (a user or a program) or a service re- 
quest, including internal and external services. 



[0064] The Next Act Retrieval 260 retrieves one act of a scenario 
at a time. This is usually the next act according to the se- 
quence of acts stored in the scenario. The sequence of 
acts can be changed with conditional statements. 

[0065] Blocks 265-290 in Fig. 5 can be considered as examples of 
internal services that are often used in the process of in- 
terpreting instructions or as responses to a prompt. 

[0066] The Translation 260 takes a set of arguments that de- 
scribe the type of the requested translation. The translate 
element invokes the Translation 260 block. Here is an ex- 
ample of using the translate element: 

[0067] <prompt action="prompt" service="com.its.connector.Sc 
enarioPlayer" 

variable="PERSON-NAME" 
translate="concatenate(REPLACE-WITH-INPUT)" 
msg="Please provide your name (First Last)" /> 
[0068] The system will find the concatenate and startWithUpperCase 
methods in the available translator service components or 
in the knowledgebase where the action is stored as an ex- 
ecutable rule. The action will concatenate a user's input 
and make sure that each word begins with the upper case. 
For example, if the input was "jeffzhuJc the first instruc- 
tion will produce "jeffZhuk" and the second instruction will 



make it "JeffZhuk". 

[0069] The Alias Retriever 270 cliecks for in-line aliases that can 
be used as the "aliases" element in the current scenario 
act. For example, the following element would instruct the 
Alias Retrieval 270 to interpret prompt responses like "Y", 
"OK", or "Sure" as "Yes". 

[0070] aliases="Yes|y|ok|sure" 

[0071] The Alias Retriever 270 can be also invoked when an in- 
struction includes the "InAliases" element that directs the 
Alias Retrieval 270 to look in the knowledgebase for a set 
of related aliases as provided in the example below. 

[0072] 

<prompt variable="TRAINING-COURSE" perform="prompt 

msg="What subject do you want to learn?" inAliases="Java 
TrainingCourses" /> 

[0073] The knowledgebase can contain a set of rules/aliases re- 
lated to course names. For example, entered keywords 
like "enterprise" or "server" will result in the name "J2EE", 
while keywords like "PDA" or "wireless" will result in the 
course name "J2ME". 

[0074] A found alias, for example, "J2EE", will be passed to the 
Scenario Modifier 250 to replace the current variable 



name "TRAINING-COURSE" with its alias value. Otherwise, 
the variable name will be replaced with the original re- 
sponse. 

[0075] The Condition Checker 275 is invoked by the "condition" 
element in a scenario act. The "condition" element is fol- 
lowed by a specified condition, one from the list of condi- 
tions, (like "exists", "lexists", "equals", etc., see the list of 
conditions in the application scenario language) and re- 
quired arguments. 

[0076] A conditional statement is usually followed by an action to 
perform. If a condition is not met (returns false) the action 
will not be performed, and the next scenario step will be 
played instead. 

[0077] For example, a conditional instruction can check if a re- 
quested training course exists. 

[0078] 

<if condition="lexists" pattern="TRAINING-COURSE" 
lastMsg="The course is not found. Enter more keywords." 
/> 

[0079] Conditional instructions, like "includes", "equals", etc. re- 
quire two arguments: a pattern and a source. 

[0080] 

<if condition="includes" pattern="TRAINING-COURSE" so 



urce="XML" 

perform="playScenario(XMLTechnologies)" /> 

[0081] The conditional instruction in the example above will 

check if a selected training course includes the "XML" key- 
word. If the condition is true the system will start playing 
the "XMLTechnology" scenario. Otherwise the next se- 
quential act of the current scenario will be played instead. 

[0082] The Query Performer 280 is invoked by the query element 
when it is present in a scenario. 

[0083] <act queryRe- 

sult="PASSWORD-QUESTION=PASSWORD-ANSWER" 
query="passwordOf(USER-NAME)" /> 

[0084] The query instruction provided in the example above 

checks in the knowledgebase for a user's record and de- 
livers one of the password questions with its answer. In 
the current example, knowledgebase records include 
more than one way to check a user's identity. There may 
be different password questions as well as password an- 
swers, and the knowledgebase would select one or more 
of them based on some rules established by your require- 
ments. 

[0085] For example, the question can be as simple as "Pass- 
word?", or more complicated like "What is your mother's 



maiden name?", etc. The question is retrieved along with 
the answer, and both are assigned to proper variable 
names. 

[0086] In the case of a successful query, the retrieved value will 
be passed to the Scenario Modifier 250 to replace the 
variable name in the current scenario. 

[0087] The Service Performer 290 is invoked by the action or per- 
form elements at the very end of the execution of an act of 
a scenario regardless of the order in which the elements 
of the act were written. Translations, alias retrievals, con- 
ditions, and queries, if any, are done before the Service 
Performer invocation. 

[0088] The Service Performer 290 transforms the action or perform 
elements into a set of arguments including a service 
name, an optional object name (if multiple objects of the 
same service class are to be used), a service operation 
name, and a set of parameters. It then passes these argu- 
ments to the Service Connector 200, which will access the 
proper service object and execute the proper service 
method. 
Application Scenario Language 



[0089] Application Scenario Language (ASL) is an XML-based lan- 
guage that describes application business flow in small 



scenarios. The scenario language constructs can be 
clianged, improved, and extended; tliey are liere in tliis 
form to illustrate the invention. Scenarios consist of XML 
elements: scenario steps or acts. Every act of a scenario is 
a prompt, a condition, or an execution step. 
Prompt the user or a partner program for an answer 

[0090] The prompt might have additional arguments, specific 
rules for input interpretation, and conditional actions. 

[0091] Here is an extract from the addKnowledge.xml scenario, 
which allows someone to introduce a new object to the 
knowledgebase. 

[0092] <prompt variable="NEW-OBJECT" service="com.its.connec 
tor.ScenarioPlayer" 
ac- 

tion="prompt" noinput="reprompt(Your input is needed)" 
translate="concatenate" 

msg="Please provide a name for your new topic." /> 
<if condition="!exists"perform="doNextStep(acceptNewO 
bject)" /> 

<act name="reject" action="query" constant="NEW-OBJEC 
T" 

lastMsg="NEW-OBJECT is not new." /> 



<act name="acceptNewObject" service="com.its.connecto 

r.KnowledgeService" 

ac- 

tion="createNewPermanent"constant="NEW-OBJECT" /> 
[0093] The prompt element of the scenario will invoke the 

prompt mechanism (method) of the ScenarioPlayer 200. The 
promptO method of the ScenarioPlayer c\aLSS works with the 
Presenter 400 component to deliver a prompt message. 
The method shifts the ScenarioPlayer Into the interpretation 
state. It will interpret the user' response and assign the 
variable provided with the prompt parameters to the value 
of the interpretation result. 
[0094] The prompt element of the XML scenario specifies the 

service-class name (comAts.connector.ScenarioPlayer) and the 
action-method name (prompt), and sets the prompt vari- 
able (NEW-OBJECT) to store the user's input. One of the 
most important arguments of the prompt element is the 
prompt message delivered to the target audience. 
[0095] The noinput and translate elements are optional interpreta- 
tion parameters. The nozn^uf element directs the program 
to re-prompt a user if the user just pressed the ENTER 
key. 

[0096] The translate element instructs the program to concatenate 



multi-word input into a single word that can better serve 
as a unique reference. 

[0097] A more complete example of the Application Scenario 

Language is provided in the attached Attachment 1 - Ap- 
plication Scenario Language. 

[0098] By providing application requirements via business rules 
with "almost natural" predicate logics, we can take a 
short-cut past several steps of the traditional develop- 
ment process, where requirements are boiled down to tra- 
ditional Boolean-logics based programs. The main reason 
is the difference between programming languages and 
ontology languages, which can be used to describe busi- 
ness rules. Ontology languages are closer to our natural 
language, and can express an unlimited number of rela- 
tionships that can be provided with predicates, while pro- 
gramming languages are extremely limited with their syn- 
tax and especially with their set of relationships. The dif- 
ference between predicate logics and Boolean logics is 
tremendous. In away, traditional development translates 
natural language requirements into Boolean logics. Predi- 
cate logics require almost no translation. 

[0099] In the example below, we use the Cyc language (CycL), by 
Cyc Corporation, to describe several rules of an educa- 



tional system. Let us say that the application allows stu- 
dents and instructors to collaborate in a group with multi- 
ple roles. A three-dimensional matrix of roles, related ac- 
cess types, and privileges describes access to documents 
and services (see Jeff Zhuk, United States Patent Applica- 
tion, Distributed active knowledge and process base, 
20010044827, Al, http://uspto.gov). 

[0100] A very powerful and simple Cyc Language constant helps 
createunUmited hierarchies. The formula below means that every 
instance of the first collection, GroupMember, Is also an instance 
of the second collection, Systemllser. 

[0101] (genls GroupMember Systemllser) 

[0102] In other words, Systemllser \s a generalization of GroupMem- 
ber. 

[0103] The genls predicate expresses the idea that one collection 

is subsumed by another. 
[0104] In the example below we can define a new function that 

will return the group role of a member. 
[0105] Here is an example of a definition for the function Mem- 

berRoleFn: 
[0106] (arity MemberRoleFn 2) 

(argllsa MemberRoleFn User) 
(arg21sa MemberRoleFn Group) 



(resultlsa MemberRoleFn GroupRole) 
[0107] vVe read this function definition as: tlie MemberRoleFn func- 
tion lias 2 parameters: user and group. Tlie function re- 
turns the specific group role that the user plays in the 
specified group. 
[0108] The following example establishes a rule with the implies 

keyword: 
[0109] (implies 

(and (hasMe 
mbershipin ?USER 7GR0UP) 

(hasRole 7USER 7GR0UP Admin) 
(hasPrivilege 7USER 7GR0UP Chan 

geMemberRoles))) 
[0110] This rule says that if a user has membership in a group 

and the user has the role of an administrator in this group 
this user has the privilege to change member roles in this 
group. 

[0111] "implies", "and", as well as "or", and "not" are important 
Cyc's logical connectives. 

[0112] The benefits of using an ontology language versus a pro- 
gramming language become even more impressive when 
application rules are more complex and have a tendency 
to change frequently. 



[0113] Application scenario language allows us to describe busi- 
ness information flow and user or program interactions. 
Application scenarios complement business rules, provid- 
ing direct access to application services. Application sce- 
nario language constructs describe service and operation 
names, define data flow conditions and provide interpre- 
tation rules for successful business operations. Applica- 
tion scenarios as well as business rules that comprise the 
application layer can be directly created by business ex- 
perts, while application services will be created by pro- 
grammers and can be considered as part of the system 
layer. 

[0114] Here is an example of the scenario for an educational sys- 
tem. The scenario allows the system to accept a new ob- 
ject and add this object to the knowledgebase, and pro- 
vides integration of the new object with existing knowl- 
edge. 

[0115] <prompt variable="NEW-OBJECT" perform="prompt" 
noinput="reprompt(Your input is needed)" 
translate="concatenate" 

msg="Please provide a name for your new topic." /> 

<if condition="!exists"perform="doNextStep(acceptNewO 

bject)7> 



<act action="query"constant="NEW-OBJECT"lastMsg="NE 
W-OBJECT is not new." /> 

<act name="acceptNewObject" service="com.its.connecto 

r.KnowledgeService" 

ac- 

tion="createNewPermanent" constant="NEW-OBJECT" /> 
<prompt variable="EXISTING-COLLECTION" perform="pro 
mpt" 

msg="Enter an existing topic name that can serve as a par 
ent to your new topic." /> 

<if condition="!exists" pattern="EXISTING-COLLECTION" 
per- 

form="reprompt(EXISTING-COLLECTION is not found in t 

he KB.) " /> 

<act query="(isa EXISTING-COLLECTION ?X)" queryResult 

="COLLECTION-QUERY-RESULT" /> 

<if condition="!includes" pattern="Collection" 

per- 

form="reprompt(EXISTING-COLLECTION is not a Collectio 
n)" /> 

<act lastl\/isg="NEW-OBJECT is integrated in the l<nowledg 
ebase" /> 



[0116] The example above prompts a user to provide an existing 
collection name that would relate a new subject to exist- 
ing data. The following statements check if the user's in- 
put is worth trusting. 

[0117] Does this parent name really exist in the knowledgebase, 
or just in the user's imagination? Does this name meet the 
requirement to be a collection? (Not every existing object 
can be a parent. Only Collection type objects can.) This 
short scenario written by business expert can be easily 
extended or complemented by other scenarios without a 
programmer"s participation. 

[0118] Examples of the constructs of the Application Scenario 
Language are provided in the attached document titled 
"Attachment 1 - Application Scenario Language". 



